perm filename TIP.DIR[D,LES] blob sn#511012 filedate 1980-05-19 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	"ARPAnet Resource Handbook" Entry
C00003 00003	Quarterly Inventory for DCA
C00005 00004	Configuration
C00008 00005	Upcoming TIP Changes
C00023 ENDMK
C⊗;
"ARPAnet Resource Handbook" Entry

			STANFORD UNIVERSITY
		ARTIFICIAL INTELLIGENCE LABORATORY


FUNCTION

	TIP	COMPUTER:  H-316	HOST ADDR. 139		IMP 11/HOST 2

ADDRESS

	Stanford University
	Artificial Intelligence Laboratory
	Stanford, California 94305

PERSONNEL

	DIRECTOR
		John McCarthy (JMC@SU-AI)	(415) 497-4430

	ASSOCIATE DIRECTOR (ACCESS AUTHORIZATION)
		Lester D. Earnest (LES@SU-AI)	(415) 497-4202

	LIAISON
		Brian P. McCune (BPM@SU-AI)	(415) 497-4971, 494-1165 x371

INTERESTS

	The SU-TIP provides authorized users with terminal access to the
	ARPAnet.

DOCUMENTATION

	See SU-AI writeup.
Quarterly Inventory for DCA

			QUARTERLY TIP INVENTORY
			 (RCS# DCA(Q) 530-49)


TIP Name:  Stanford University (SU-TIP)		Date:  30 April 1979

MLC	Type	  Baud		Modem or Terminal	Sponsor		Users
Port #	D-Dialup  Rate		Manufacturer
	L-Leased		and Model #
	R-Room

01	D	110-300		Bell 113D		DARPA/IPTO	any
02	D	110-300		Bell 113D		DARPA/IPTO	any
03	D	110-300		Bell 113D		DARPA/IPTO	any
04	D	110-300		Bell 113D		DARPA/IPTO	any

10	D	150/1200	UDS "Stanford"		DARPA/TTO	SCI-ICS
11	D	150/1200	UDS "Stanford"		DARPA/IPTO	SU-AI
12	D	150/1200	UDS "Stanford"		DARPA/IPTO	SU-AI

20	D	1200		Vadic 3400		DARPA/IPTO	SRI-KL

30	R	110		Teletype Model 33	DARPA/IPTO	SU-AI
31	R	600		SU-AI TTY port		DARPA/IPTO	SU-AI
32	R	2400		Lear Siegler ADM-3A	DARPA/IPTO	SU-AI

Note:  "any" means any federal agency or contractor


Submitted by:  Brian P. McCune, SU-TIP Liaison
Configuration

port #	telephone number	owner	contact
01	494-9024		ARPA	BPM
02	494-9025		ARPA	BPM
03	494-9026		ARPA	BPM
04	494-9027		ARPA	BPM
10	493-3280		SCI	BPM
11	497-1112		SU-AI	BPM
12	497-1113		SU-AI	BPM
20	494-8787		SRI	GFF
30	hardwired Teletype	SU-AI	BPM
	Model 33
31	hardwired SU-AI TTY	SU-AI	MRC
	port
32	hardwired Lear Siegler	SU-AI	HPM
	ADM-3A

port #s	use			parameters
01-07	110-300-baud dialup	hunting
	(Bell 113D modems)
10-17	150/1200-baud dialup	150-baud input, 1200-baud output, nonhunting,
	(UDS "Stanford"        	7-bit ASCII, no padding, no 37 parity, not wild,
	modems)			with insert linefeed, echo remote,
				intercept esc, transmit every 0
20-27	1200-baud dialup	same as for ports 10-17, except 1200-baud input
	(Vadic modems)
30	inhouse hardwired	hunting
31	600-baud SU-AI TTY	same as for ports 10-17, except 600-baud input
	port			and output
32	2400-baud hardwired	same as for ports 10-17, except 2400-baud input
				and output
33-37	inhouse hardwired	hunting
40-77	unused			hunting

∂06-Dec-78  1155	MALMAN at BBN-TENEXE 	port 32 parameters
Date:  6 Dec 1978 1456-EST
From: MALMAN at BBN-TENEXE
Subject: port 32 parameters
To:   BPM at SU-AI

Brian,
OK, I will have the TIP reloaded tonight with the new parameters.
Here is a copy of the new buffer assignments.


IBM 2741 DEVICE HANDLER LOADED


DEVICE CODE EXTRA HANDLER LOADED

       
TIP 420 DEVICE BUFFER ALLOCATIONS FOR SU

1	6	106	214
10	13	106	431
20	22	106	431
30		106	214
31		106	431
32		106	431

BREAKAGE:  4	4         

35 SECONDS RUN-TIME
26 PAGES USED

joel
-------
Upcoming TIP Changes

∂08-Sep-79  0359	MALMAN at BBN-TENEXE 	TIP parameter changing 
Date:  8 Sep 1979 0655-EDT
From: MALMAN at BBN-TENEXE
Subject: TIP parameter changing
To:   Stephenson at ISI, Maull at BBN, Jones at I4-TENEX,
To:   TFinn at SRI-KL, Quilici at ISIE, McCarty at OFFICE-1,
To:   DCEC-R820 at BBNB, DOCB at OFFICE-1, Judd at OT-ITS,
To:   RJames at ISID, AFGWC at BBNB, Lockard at ISI, Gamble at BBND,
To:   OAF at MIT-MC, POH at ISI, Dames at OFFICE-1,
To:   Neilsen at NBS-10, Dagrm at SRI-KL, Norman at ISIE,
To:   Muir at ILL-UNIX, Walker at RADC-MULTICS, Shell at RAND-RCC,
To:   BPM at SU-AI, James at SRI-KA, Pepin at USC-ECL,
To:   Weidel at USC-ECL, Ruggeri at ISIE, Bubba at ISIE,
To:   Jansen at BBN
cc:   Santos, Mimno, Frye, RHillegas, Malman at BBN-UNIX

Group,
Please direct your requests for TIP parameter changes to Rick Hillegas
(RHillegas@bbne) from now on. Rick will also be available to answer user
questions and problems. You will able to reach him through the
Network Control Center or directly at (617) 491-1850.

Regards,
joel
-------

∂11-May-79  1943	Feinler at SRI-KL (Jake Feinler) 	TIP Login  
Date: 11 May 1979 1934-PDT
From: Feinler at SRI-KL (Jake Feinler)
Subject: TIP Login
To:   [SRI-KL]<NETINFO>LIAISON-5-79:


Subject: TIP login

     At the November 1978 Sponsors' Group meeting ARPA and DCA
launched a project to implement "TIP login".  This means that a 
terminal user will have to identify himself to the TIP before 
any network connection can be opened.  It is being implemented to
control access to the network.

     Presently there is not enough core storage in the TIPs to 
implement the necessary code.  Also, we have recently received a 
number of complaints about insufficient buffer space in the TIPs
to handle new terminals being added.  We are therefore proposing
three changes which will free up needed core.

1.  Once again, we will deactivate "old Telnet".  We believe all
previously identified problems with new Telnet within the TIP
have been resolved.  Also, host servers have had over three 
years to implement new Telnet.

2.  We propose to abolish "remote controlled Telnet echoing"
(RCTE).  This is a set of negotiated Telnet options which 
provide a choice of echoing modes.  It has been on-line in various
stages of completion for three years but is not widely used.
Removal of RCTE would return the largest amount of storage of
the three changes, about 600 (decimal) words.  On the balance, 
the general welfare of the network will be better served by
replacing it with the TIP login code.

3.  Code to support the IBM 2741 will be removed from all TIPs.

     DCA requests comments on these proposals by 15 June, 1979.  
Please be sure you info your sponsoring agency.  Tentatively
1 December 1979 is proposed to remove the old code, with cutover
of TIP login in January 1980.

Maj. Raymond E. Czahor
Chief, Arpanet and Special Network Mgmt. Br.
DCA

-------

∂16-May-79  0413	MALMAN at BBN-TENEXE 	tip login    
Date: 16 May 1979 0715-EDT
From: MALMAN at BBN-TENEXE
Subject: tip login
To:   BPM at SU-AI

Brian,
Basically all hosts will be "forced" to change their code to accept
a coded password from a "network login server" as verification of a user.
The user will then only have to login once (to the "network
login server").

Hosts that are slow in changing their code to accept this will have to have
their users login twice. (once the the "network login server" and once to
the host itself (as usual).

Hope this is clear enough...

joel
-------

∂16-May-79  2222	BPM  	TIP 2741 option    
To:   DCACode535 at USC-ISI
CC:   EJF at SU-AI, Malman at BBN-TENEXE    
Dear DCA,

Following is a note from an IBM 2741 user (Erik Gilbert--EJG@SU-AI) who
would like to see TIP support for 2741s continued.  I originally had the
2741 code loaded in the SU-TIP because a number of people at Stanford
University access the ARPAnet from 2741s.  This terminal is found all over
campus because of the many IBM 370s in use, e.g., at the Campus
Computation Center, Medical School, and SLAC.  I don't know how many
people are tied to 2741s.  It probably is on the order of magnitude of 10,
but certainly not as low as 1 or high as 100.

	Brian

---------------------------

 ∂16-May-79  1619	EJG  	New TIP lossage    
Brian, could you add the following to the list of votes about the
new TIP changes:

I'm not real thrilled about TIP login, but if it has to come, it has
to come.  My real complaint is about 2741 compatibility flushing.
My work at Stanford occasionally requres me to work at SLAC, and
the only "reliable" dialup access I have found there is a crufty
old 2741.  I was quite pleased to discover that I could use this
terminal to log onto SAIL from SLAC, for mail reading and cross-
checking of files related to shared programs.

It will certainly not cause my work to stop in its tracks to remove
this capability, but it seems very unfortunate to remove a feature
which increases compatibility in world which is already overly
incompatible in terms such as magtape formats, floppy formats,
modem protocols, etc.